Wow! It's very cool and useful for people like me)

Wow! It's very cool and useful for people like me)

Thank you! I've been making steady progress, but it probably won't be ready for a while (which is why this is a draft).

Added partial support compound bodies - all child shape types.
Also working on convex and concave mesh support... it'll be a while.

wow

Finally got convex hulls working 🥳 🎉

Still have to optimize and bug fix everything and add more features

@MasterThomas15 Your forces should be fixed in the latest commit, and I added a few new simulation utilities (get gravity/maxsubsteps and step simulation with user-provided parameters)

The previous commit uses the new ESM stuff to do Scratch.external importing instead of pasting the entire libraries, this reduces the file size by like 89% (1000KB —> 108 KB) and makes it much easier to read

Tradeoff is that it doesn't seem to work in my version of the Desktop editor, which I don't think has been updated yet?

I'm not normally one to do this, but I think it'd be nice if I could have everyone review this PR just because it's so big.
I don't care how much time you take, I don't care if you don't do it, I understand it likely won't be merged, but as many eyes as possible would be very helpful.
Thanks so much everyone!

When projects using this extension are packaged, will the packager embed the external dependencies into the packaged project so projects that use the extension can be used offline?

if this is merged, projects using it will work fine offline

before then, no currently the packager does not know how to convert all the Scratch.external.* into an inline thing on its own yet

if this is merged, projects using it will work fine offline

before then, no currently the packager does not know how to convert all the Scratch.external.* into an inline thing on its own yet

Wait so you mean when it's merged, the builder will convert it into a data url, but the internet url currently in the extension can't be packaged?

oops wrong button

Also validate is yelling at me

extensions/MasterMath/AmmoPhysics.js: Error: https://raw.githubusercontent.com/Brackets-Coder/AmmoPhysics/refs/heads/main/dependencies/ammo.min.js is not a known immutable URL. npm packages need to be pinned to an exact version. Git repositories need to be pinned to an exact commit hash. Extend isImmutableURL() in development/dependency-management.js if this is false positive.

it's telling you to use a specific commit and not just whatever is on the main branch

I have a few trivial inquiries for any who may be able to help:

1. The URL of the ammo physics library points to a custom build on my repository. Is this acceptable, or do I need to use a different one? I didn't want to use the one on NPM because it isn't as optimized.
2. Some of the blocks use third-party icons found in the Blender source code. I've added a link to where I found them, but do I also need to include Blender's license in the code?

The more complex questions

3. The extension automatically clears all bodies and rays and resets the world upon the project starting. This is used as a memory management tool, but will some users find it unintuitive? Some rely on project data persisting even after green flag click and there's a "reset world" block that does the same thing. Do I need to add some kind of toggle to enable or disable the automatic resetting?
4. With the custom build, WebAssembly and another build flag enables scalable memory. This prevents a crashing bug and allows projects to have very large-scale physics simulations, but some browsers may automatically reload the page or the page may crash if it uses too much memory. Additionally, I have some concerns about an undiscovered memory leak in the code (although I have been very careful with my memory management), because once in a blue moon I'll see a Turbowarp warning that the renderer process crashed, and the page freezes. This is rare and only occurs in extreme scenarios, but is it a dealbreaker and does it need to be fixed prior to merging?

About 3: From the point of view of a potential user of your extension (still need to test if it is viable for my projects but it looks really nice already), I would definitely like to have the flexibility of being able to turn off automatic resetting, I'm a big fan of having options for everything and I'm probably not the only one

Noted

I was also previously considering putting an "Advanced Options" button at the bottom of the pallet that would reveal additional blocks (such as visual debug rendering, but this has since been scrapped due to scope). I could still do this for a few smaller options

Also, for me (on the newest version, git cloned desktop with NodeJS and unrestricted mode), the current version in your repo throws an error when loading: Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'evalAndReturn') at 21:39 at 2584:3

that would mean your vm is outdated

Also, for me (on the newest version, git cloned desktop with NodeJS and unrestricted mode), the current version in your repo throws an error when loading: Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'evalAndReturn') at 21:39 at 2584:3

The latest version of the extension makes use of the relatively new external dependency features. It's working for me on the latest version of Turbowarp desktop from the Mac app store, but if it's not working for you I'd recommend just using the web editor as that's almost always up to date

that would mean your vm is outdated

Is that actually a possible issue, even if I just cloned everything into a completely new environment about 10 minutes ago?